도메인 주도 설계 첫걸음-Vlad Kononov

README

Giftogether 서비스를 개발하면서 새 기능을 추가하는데 기존 기능들에 영향을 가지 않게 설계하기 위해 도메인 로직을 먼저 작성하기 위해 DDD를 찾아봤다. 여러 블로그글이 NestJS를 위한 도메인 주도 개발 방법론이 나와있지만 그걸로는 부족해 책을 한 권 구매했다. 이 책을 읽으면서 비즈니스 로직을 도메인 영역으로 옮겨 실제 구현코드와의 링구아 프랑카를 작성하는 능력, 소통하는 능력을 기르길 희망한다.

2024-12-12 목차, 서문, 맺음말, 부록 A

서문과 목차, 그리고 맺음말과 부록의 마켓노퍼스 사례 연구를 먼저 읽어봤다. 아직 용어가 대부분 정립이 되어있지 않아 애그리게이트, 유비쿼터스 언어, 도메인 모델과 하위 도메인 모델이 쏟아지지만 저자는 내가 마치 이 책을 다 읽어본 것처럼 능수능란하게 이야기했다(당연하겠지 맺음말이니까).

오히려 단어 자체의 정의를 먼저 들여다보기 전에 어떤 맥락에서 사용되는지 넘겨짚으니까 많은 생각을 할 수 있었다. '애그리게이트' 라는 단어는 어떤 도메인 모델에 기능을 붙일때 쓰이고 트랜잭션 경계와 긴밀하게 얽혀있다는 것을 알았다. '하위 도메인 모델' 은 그 중요도와 변동성 등에 따라서 핵심 하위 도메인, 일반 하위 도메인, 지원 하위 도메인으로 나뉘며, 그다지 중요하지 않은 하위 도메인의 경우엔 단순히 '액티브 레코드' 스크립트만 사용해도 좋다고 한다 👀? '유비쿼터스 언어' 야 말로 회사가 돌아가는 업무 언어를 식별하는 수단이고, 유비쿼터스 언어가 잘 정의되어 있으면 의사소통에 굉장한 도움이 되기 때문에 선택사항이 아니라고 두 번 강조했다.

Scraps

• 모델은 실제 엔티티를 복사해선 안된다. 모델은 문제를 해결하기 위해 다른 문제를 배제한다. - p.47

• 트랜잭션 스크립트는 프로시저를 기반으로 시스템의 비즈니스 로직을 구성하며, 각 프로시저는 퍼블릭 인터페이스를 통해 사용자가 실행하는 작업을 구현한다. - p.65

  • 트랜잭션 스크립트는 그 단순함 때문에 복잡한 비즈니스 로직에서 바로 활용될 수 없다. 이는 지원 하위도메인에 적합하다. ETL (Extract Transform Load)에 적합하다.

• Active Record 액티브 레코드는 DB 테이블 또는 View의 행을 감싸고 DB 접근을 캡슐화하고 해당 DB에 도메인 로직을 추가하는 객체이다 - p.72

  • ORM은 액티브 레코드를 추상화한 것이라고 봐야지.
  • 액티브 레코드 스크립트는 지원 하위 도메인, 일반 하위 도메인에서 사용되며, 복잡하지 않은 비즈니스 로직에서 자주 활용된다.

• 그물같은 의존성, 규칙과 요구사항이 로직에 영향을 주는 경우, 도메인 모델 패턴을 사용한다. - p.79

• 도메인 모델은 행동(behavior)과 데이터 (data) 모두를 포함하는 도메인의 객체모델이다. - p.80

  • Aggregate, Value Object, Domain Event, Domain Service 등

• Value Object를 다른 객체의 속성을 표현하는 도메인의 요소로 활용하라. - p.87

  • VO는 불변이고, 필드가 일치하면 동치. 모든 오퍼레이션은 새 VO 인스턴스를 만든다. 엔티티이 속성을 설명하는 데 VO를 사용하면 원시 집착 코드 냄새 (primitie obsession code smell) 을 피할 수 있다.

• Aggregate는 Entity이다. 명시적인 식별필드가 필요하고 인스턴스 생애주기 동안 상태가 변할 것을 기대할 수 있다. Aggregate는 Entity를 포함하는 슈퍼셋니다. 이 패턴의 목적은 데이터의 일관성을 보호하는 데에 있다. - p.89

• 외부 Aggreagte를 참조할 때 ID를 이용하는 것은 이 같은 객체가 Aggregate 경계에 속하지 않음을 명확히 하고 각 Aggregate가 자신의 트랜잭션 경계를 갖게 보장하기 위함이다. - p.95

• Aggregate Root의 퍼블릭 인터페이스 외에도 외부에서 Aggregate와 커뮤니케이션 할 수 있는 메커니즘이 있는데, 바로 Domain Event이다. p.96

• Ubiquitos Language: 참가자들이 효과적으로 소통하기 위해 변환에 의존하지 말고 같은 언어를 쓰는 것이다. p.25

• 하위 도메인은 발견하고, 바운디드 컨텍스트는 설계한다. 하위 도메인은 비즈니스 전략에 의해 정의된다. 그러나 SW 엔지니어는 특정 프로젝트의 컨텍스트와 제약조건을 해결하기 위해 바운디드 컨텍스트를 설계할 수 있다. - p.43

  • 하위도메인은 유스케이스 집합과 유사하고 비즈니스와 밀접한 연관성을 띄고 있다.
  • 바운디드 컨텍스트는 모델의 결계를 선택하고 비즈니스 도메인을 가지고 문제를 풀기 위한 모델을 구축한다. → 동일해 보이는 하위 도메인을 풀기 위해 모델링의 결과가 더 구체적이고 전술적이 될 수 있다.

Questions

• Active Record Pattern을 애플리케이션 레이어에서 캡슐화를 시켜야 할까
• 도메인 서비스와 애플리케이션 서비스의 차이는?